Processing buffered data

ABSTRACT

Data reception apparatus for receiving and processing a data stream including a stream of data units, the data apparatus comprising: a buffer, a data reception controller for receiving data units from the data stream, storing received data units in the buffer, and if the amount of data from the data stream that is stored in the buffer exceeds a predetermined generating a buffer load interrupt for the data stream; and a processor responsive to the buffer load interrupt to: a) disable handling of further buffer load interrupts for the data stream; and b) repeatedly activate a routine to process a single data unit from the data stream that is stored in the buffer until all the data units in the buffer have been processed and then reset the buffer.

This invention relates to apparatus and methods for processing buffereddata.

There is an increasing number of applications in which data istransferred between a transmitter and a receiver as a plurality of datastreams over a single logical link. The data streams can be segmented atthe transmitter into packets, each of which contains some data from thedata streams. Usually, but not necessarily, each packet contains datafrom only one of the data streams. The packets are then transmittedindependently over the link. When the packets are received at thereceiver they are reassembled so as to re-form the data streams.Advantages of this system over conventional analogue techniques are thatthere is no need for a dedicated link or channel to be assigned to eachof the data streams; that interference in transmission may affect onlysome of the packets, leaving some data streams unaffected; and thatpackets may be routed to the receiver over any available physical linkand still combined properly to re-form the data streams even if thepackets arrive out of order.

Each packet normally includes control data that allows the packet to bere-assembled properly by the receiver. This may comprise data indicatingthe data stream whose data is included in the packet, and a serialnumber for the packet so that the packet can be combined in the correctorder with others from that data stream. The control data can alsocomprise error check data such as a checksum for allowing the receiverto verify that the packet has not been corrupted during transmission.

One application for the above technology is in the delivery of digitalvideo signals to households via cable or satellite links. Digital videostreams may be packetised and then broadcast to household receivers. Auser of a receiver may then select one of the streams for viewing. Thereceiver can then reassemble that video stream from the receivedpackets, convert it to a form suitable for input to the user'stelevision and then output the resulting signal to the television. Ithas been proposed that such systems could offer additional features.These features include the storing of received streams for laterviewing, and the displaying of program guides (lists of programs withtransmission times) which could be assembled by the receiver fromcertain transmitted packets.

FIG. 1 shows the transport packet stream syntax specified in ITU-Tstandard H.222.0, equivalent to ISO/IEC standard 138181. (Further detailof the structure is available from the standard itself, the contents ofwhich are incorporated herein by reference). FIG. 1 is equivalent toannex F.0.1 of the H.222 standard. The transport stream 1 comprises astream of packets, each of which consists of 188 bytes. Each packet hasa variable length header illustrated at 2 and a payload which occupiesthe remainder of the packet. The header has the following structure:Number of bits Signification 8 Synchronisation byte 1 Transport errorindicator 1 Payload unit start indicator 1 Transport priority 13 Program Identification (PID) 2 Transport scrambling control 2 Adaptationfield control 4 Continuity counter Variable Adaptation field

The structure of the adaptation field is shown in more detail in FIG. 1.

Data representing video, audio, system information such as programguides and other user data streams can be carried as PES packets, whichcan be included in the payloads of the transport stream packets. Thestructure of a PES pack t is shown in FIG. 2. FIG. 2 is equivalent toannex F.0.2 of the H.222 standard. Each PES packet comprises a 24 bitpacket start code prefix, an 8 bit stream identification, 16 bitsindicating the length of the PES packet, an optional variable length PESheader and PES packet data of variable length.

FIG. 3 shows that the PES packets together form part of a programstream, whose structure-is shown in FIG. 3. FIG. 3 is equivalent toannex F.0.7 of the H.222 standard.

In addition, section data can be carried in the packets. The sectiondata can include information that is to be interpreted by the decodingunit. For example, section data may include:

-   -   1. data that is to be assembled by the receiving unit into a        program guide indicating the programmes that are to be provided        on a channel;    -   2. data that is to be assembled into code that can be executed        by an interpreter (an “o-code interpreter”) in the receiving        unit; and/or    -   3. data that is to be assembled into decoding keys to allow the        receiving unit to decrypt encoded data transmissions such as        pay-per-view video.

The overall structure of an H.222 packet containing section data issummarised in FIG. 4, which shows schematically some important featuresof the packet. The packet comprises a header 5, an adaptation field 6and a payload 7. The header includes a payload unit start bit 8 and aprogram identifier (PID) 9. The payload includes one or more sections 10and, if the payload unit start bit is set, a pointer field 11 whichindicates the offset x to the start of the first new section (theintervening bits of the packet may represent tail data of a precedingsection). Each section includes information giving the length of thatblock, and periodically a section includes CRC (cyclic redundancy check)data for it, in order for the receiver to check that section has beencorrectly received.

A receiving unit can check that a contiguous group of blocks of dataforming a section has been received correctly, by calculating a CRCvalue for the section once it has been received and comparing thecalculated CRC value with the received CRC data or, for example, apreset value. If there is the required match then it is assumed that thedata has been received correctly. If there is not the required matchthen the whole section as received is discarded. Retransmission of thesection may then be requested, or the receiver may assume that theincorrectly received section has been lost and continue by receiving thenext section. In one such checking method a counter is maintained at thereceiver, with an initial value of −1. Every incoming byte is combinedin turn with the value in the counter to create a new value. The 4 bytesof CRC data at the end of a section are of the values such that if theyand the rest of the section have been correctly received then afterthose 4 bytes have been combined in turn with the counter the value ofthe counter will be zero. A final value in the counter that does notmatch zero indicates that data has been corrupted.

When data is received it is conveniently stored in a circular buffer.The circular buffer is defined by a series of memory locations togetherwith a pair of pointers indicating the current locations at which datashould be written and from which data should be read in the buffer. Thepointers are wrapped at the boundaries of the span of the memorylocations so as to give the buffer its circular nature.

The consumer of data from the buffer updates the read pointer aftertaking data out of a buffer, and the write is updated after placing datain a buffer. However, this approach has the problem that if data ismultiplexed and can span several transport packets, a buffer may havedata added to it over a long period of time before an entire section orPES packet has been collected. If an error is discovered within thetransport stream the PES packet or section may be in error.

According to one aspect of the present invention there is provided datareception apparatus for receiving and processing a data stream includinga stream of data units, the data apparatus comprising: a buffer, a datareception controller for receiving data units from the data stream,storing received data units in the buffer, and if the amount of datafrom the data stream that is stored in the buffer exceeds apredetermined amount, generating a buffer load interrupt for the datastream; and a processor responsive to the buffer load interrupt to: a)disable handling of further buffer load interrupts for the data stream;and b) repeatedly activate a routine to process a single data unit fromthe data stream that is stored in the buffer until all the data units inthe buffer have been processed and then reset the buffer.

According to a second aspect of the present invention there is provideda method for receiving and processing a data stream including a streamof data units, the method comprising: receiving data units from the datastream; storing received data units in a buffer, and if the amount ofdata from the data stream that is stored in the buffer exceeds apredetermined amount, generating a buffer load interrupt for the datastream; and performing processing by means of a processor responsive tothe buffer load interrupt to: a) disable handling of further buffer loadinterrupts for the data stream; and b) repeatedly activate a routine toprocess a single data unit from the data stream that is stored in thebuffer until all the data units in the buffer have been processed andthen reset the buffer load interrupts. Data reception apparatus asclaimed in claim 1, wherein the processor is arranged to activate thesaid routine in response to a semaphore indicating that data in thebuffer is to be processed.

Suitably the routine is arranged to deactivate the semaphore. Preferablythe routine is arranged to call a subroutine to determine whether ailthe data units in the buffer have been processed operable by theprocessor and if all the data units in the buffer have been processed toreset the buffer load interrupt and otherwise to activate the semaphore.The said subroutine may be arranged to reset the buffer if all the dataunits in the buffer have been processed.

Suitably the data reception apparatus is provided on a single integratedcircuit.

The data stream is suitably formed of packets. The data units may becomprised within the packets, for example as payload data or sectiondata. The data stream may be in accordance with the ITU-T H.222 standardor a derivative thereof.

The present invention will now be described by way of example withreference to the accompanying drawings, in which:

FIGS. 1 to 4 illustrate aspects of the H.222 standard for packet datatransmissions;

FIG. 5 shows the structure of a decoder unit and associated equipmentsand

FIG. 6 illustrates the structure of a buffer and associated pointers.

FIG. 5 shows the general structure of a decoder unit 12 and ancillaryequipment for handling an H.222 feed and outputting a video, audio,graphics or other feed to a suitable output unit such as a television orhi-fi. In this example the H.222 feed is received from satellitebroadcast radio signals by satellite receiver dish 13. The satellitedish is connected to a tuner 13 b which selects a single transponderchannel of the satellite's transmissions under the control of a signalreceived over link 13 c from the decoder unit 12. The transponderchannel bears an H.222 packet data feed which may include data for anumber of video and audio channels. The data from the transponderchannel is sent over link 14 to the decoder.

The decoder includes a main memory 15 which may be implemented on one ormore dedicated memory chips (integrated circuits) and a processingsection 16 which may be implemented on one or more integrated circuits.The processing section includes a local memory 17, a processing unit 18which runs software stored in memory 17 and a transmissioncontrol/peripheral transport interface (TC/PTI) unit 19 which isconnected to memory 15 and memory 17 for transferring data rapidlybetween the two. The processing unit 18 is also connected to memory 15.The processing section has direct memory access (DMA) to memory 15.

The software code stored in the main memory is of three general types:user code, which includes code for interpreting program guidestransmitted to the decode, for drawing graphics and for running“o-code”; PTI code together with drivers for output protocols such asaudio, UART, tuner and video; and TC code. The user code can make callson the PTI code. The user code and the PTI code together provide thesoftware for decoding incoming data. The TC code provides the softwarefor handling the error checking and demultiplexing of incoming data.

Program guides are built up from section data received by the decoderfrom time to time. The program guides are then stored by the decoder sothat they can be displayed for a user when requested. Code for executionat the receiver or a subsequent processor can also be downloaded. O-codeis one example of such downloadable code. O-code can be assembled fromsection data received from time to time. O-code represents softwareinstruction code that can be run when required under the supervision ofthe o-code interpreter. O-code can be used, for example, for providinginteractive advertisements, games or home shopping applications.

An output section 20 is provided in the decoder 12. The output sectionis connected to the memory 15 and the processing section 16. The outputsection is capable of performing relatively high level decoding and/ordecompression for generating suitable output signals from the decoder.For example, the output section may be capable of decoding received MPEGor JPEG data. The output from the output section may pass to an outputunit such as a television 21. The decoder includes an alternate output22 for providing access to low level representations of the receiveddata, for example cleaned and/or descrambled versions of the inputstream to the decoder. This may be used by, for example, a digital videorecorder 23.

The decoder also includes a control interface 24 for low speedbi-directional communication with a data service provider. In theexample of FIG. 5 the control interface takes the form of a modem whichis connected via a telephone line 25 to the service provider. Thecontrol interface provides a means for the decoder to request programsfrom the service provider.

In use the satellite may provide 32 transponder channels. One of theseis selected by the receiving equipment (either fixedly or under usercontrol). The selected transponder channel, which may be able to provide8192 individual PID (program identification) streams, may carry 5 or 6video channels and associated audio channels and support data such asprogram guide information. The user code defines a set of (e.g. 48)PIDs, and received packets bearing those PIDs are detected on thetransponder channel and processed.

Under the H.222 standard each received packet may contain section dataor PES data. Each packet may contain data from only a single PID Apacket containing PES data may contain data from only a single PESpacket. A packet containing section data may contain data from one ormore sections. See, for example, annex F.0.2-6 of the H.222 standard.

When the user code selects (either automatically or under the control ofthe user) that data from a PID is to be received it transmits the valueof that PID to the processor 18. The processor stores the value of thatPID in its local memory. The PID information in each incoming packet iscompared with the stored PIDs. Packets not bearing one of the stored PIDare discarded. If the specified PID is a section PID then the user codealso specifies 8 bytes of selection data. When section data for that PIDhas been received bytes 0 and 3 to 9 of the section data (i.e. the startof the section header omitting bytes 1 and 2 which indicate the sectiondata's length) are masked with the 8 bytes of selection data if there isno match then the section data is discarded. This feature allows a userto filter out unwanted section data When the end of a section is reached(as indicated by the received section data) the processor deletes thePID of that section from local memory to terminate reception of datafrom that PID.

One commercial use of the apparatus described above is as a hardwareplatform for implementation of set top box decoders (or other types ofdecoders) by applications programmers. In that situation the hardware asdescribed above would perform the basic decoding functions, and the usercode stored in the main memory could be developed by an applicationsprogrammer for a specific implementation. In designing the hardware forthat use, it is highly preferable to substantially optimise the hardwarefor fast decoding of incoming data without the need for intervention bythe user. One area where this is pertinent is in the decoding andbuilding up of section data that is to be used by the user code tointerpret, for example, program guides. As described above, a block ofreceived data (whether PES or section data) is not known to be validuntil all parts of it have been received, including any check data. Inprior art systems it has been necessary for the user code to takeaccount of this and to be aware that error checking of the receivedsection data may make it necessary to discard data.

The present system may be implemented as a hardware peripheral forsupporting demultiplexing of, and data extraction from a transportstream. The transport stream is a stream of data traveling between adata source and a user of the data. The present example will bedescribed with reference to a transport stream that is a DVB standardtransport stream in which data from up to 8192 PIDs is packed into 188byte transport packets and multiplexed together. The hardware alsosupports the copying of a portion of this data and possible addition ofalternate data back out of the device.

The software that resides on this peripheral may interact with a user ofthe data by means of memory space that is shared between the two.

The transport control (TC) hardware is suitably implemented as a 16 bitprocessor. The processor may be a processor component of a largerintegrated data processing device. TC software (TC code) resides on theTC hardware for performing the transport and data extraction functions.The TC code uses data in shared SRAM to control its operation. There isdata describing 48 slots each of which can collect data from 1 PIDwithin the transport stream. Some slots send data directly to otherdevices, and some place data in circular buffers in the shared memoryspace. There are also data tables containing descrambling keys to allowdescrambling of video or other data, section filter state tables, andother useful data.

The data is suitably carried in the form of PES packets. These may beunits of data for, for example, video, audio or teletext. The PESpackets can occupy many transport packets (consecutive in the PID butnot in the transport stream), but are packed with stuffing bytes so thatany transport packet contains data from only one PES packet. Sectionsare also defined in the data. Sections are blocks of data from 3 to 4096bytes. Sections may span several transport packets. The transportpackets may contain numerous of sections, starting at any offset fromthe head of the packet. Thus the tail end of a section from a previouspacket (having the same PID) could conceivably take up most of a packet.

Each circular buffer has a descriptor in the shared SRAM. In the priorart, one route to describing the state of such a buffer is by means oftwo pointers: a read pointer and a write pointer. The consumer of datafrom the buffer updates the read pointer after taking data out of abuffer, and the write is updated after placing data in a buffer. Aproblem with this approach is that since data can be multiplexed and canspan several transport packets, a buffer may have data added to it overa long period of time before an entire section or PES packet has beencollected. If an error is discovered within the transport stream the PESpacket or section may be in error. In the present system the state ofeach buffer is described by three 3 pointers: a read pointer, a writepointer and a quantized write pointer. The standard 2 pointer model hasread and write, the consumer updates read after taking data out of abuffer, and the write is updated after placing data in a buffer.

In the present system, three pointers are used: a read pointer, a writepointer and a quantized write pointer. The quantized write pointer isonly updated when a valid complete section or PES packet has beencollected. If an error is detected the temporary write pointer isoverwritten with the quantized pointer, thus effecting a windback of thebuffer, and removing the possibility of the buffer containing a partialsection or PES packet.

In a preferred implementation of the present system the supports anumber (e.g. 64) of interrupt bits which are separately maskable,settable and acknowledgable. The TC hardware is then able to codeset theinterrupt bit for each slot when a completed PES packet or section hasbeen collected for that slot. When data arrives frequently it ispossible for a large number of interrupts to be generate, degradingsystem performance. Also given one interrupt the software may need tohandle one or many input PESs packets or sections.

The present system is arranged so that the interrupt handler disablesfurther interrupts on a slot when it receives the first interrupt, tosignal to the inputting process and to have the input process functionin a simple loop of the form:

-   -   while true        -   wait on data present semaphore        -   handle one section or PES packet        -   call function to update read pointer to after the handled            section/PES packet

The function that updates the read pointer also checks to see if anydata remains, or has arrived, in the circular buffer, if data is presentit re-signals the data present semaphore, if not then it re enables theinterrupt. This simplifies the input process to a simple loop, andreduces interrupt traffic by leaving the interrupt disabled until theinputting process has consumed all data in the input buffer, includingany that arrived during processing of the data that was present when itwas first signalled.

By means of this approach the main loop set out above for processingdata can continue to run unaltered when the buffer overflows. Thestepwise operation of the loop is under the control of the data presentsemaphore By returning the data present semaphore to its set or truestate after a section has been handled or processed, the loop can becaused to continue unpaused until all date has been read. Then theinterrupt can be reset or disabled.

It is generally very difficult to debug the software on a peripheralsuch as the present unit since when running normally there is no way tomonitor the instruction pointer or registers at anything approachingreal time, and there is no breakpoint mechanism available. Also,debugging an interrupt handler is especially difficult since in aworking system it is undesirable to interfere with the execution of thehandler.

In the present system a macro called debug_event is called at variouspoints in the code. This macro takes as a parameter a constant value orregister to be written into a buffer in the shared SRAM, for the TCcode, or in an unused region of the main memory for code running on themain processor unit that is to receive data from the TC unit. Two othermacros are called during initialization of the code: print_debug_eventsand initialize_debug_events; (which are called in that order) to printdebug information from the previous run and initialize the buffers forthe current run.

This method of displaying debug at the start of the next run allows fora method of debugging code that it is not wished to greatly perturb, andwhich may completely crash the processor, which cannot be examined inother ways.

The TC is suitably embodied as a 16 bit processor without a carry flag.Incoming data can be stored via a DMA engine into a circular buffer,which wraps around. When a section or PES packet is completed, thereturned address for the end of that section or packet is not wrapped.It is possible, for example, that if the system is three bytes from theend of the buffer and a 6 byte section arrived for processing 3 byteswill be stored at the end and 3 at the beginning, but the address of theend of the section could be given as 3 bytes beyond the end of thebuffer. To address this, this case is recognised and the address fixedup to three bytes from the beginning of the buffer. If the address is a32 bit address and the TC is a 16 bit device without a carry flag (butwith zero and sign flags) a special algorithm can be provided to do thefixup. The algorithm is given below, where ptr is the returned address,top is the end of the buffer, and base is the base of the buffer. Highand low refer to the 16 bit portions of the 32 bit values: ; Note VH =ptr high VL = ptr low ;  TH = top high TL = top low ;  OH = offsethigh OL = offset low ;  BH = base high BL = base low ; ; Pointerwraparound algorithm is :- ; ;   1/ Find offset = (Pointer − TOP) if ;   its −ve then no wraparound ; ;     Calculate OH = (VH − TH) if −veexit ;     if(VL and TL same sign) ;      Calculate OL = (VL − TL) ;      if result +ve then we have wraparound ;       else carry, OH−, if−ve exit ; ;     else( VL and TL different sign) ;      Calculate OL =(VL − TL) ;       if(TL −ve) carry, OH−, if −ve exit ;       else wehave wraparound ; ;   2/ Now have OH and OL, calculate ;    wrappedpointer = (Base + Offset) ; ;     VH = BH + OH ;     if( BL and OL notsame sign) ;      calculate VL = BL + OL ;       if(VL +ve carry) VH++ ;    else ;      calculate VL = BL + OL ;       if( both were −ve thencarry ) VH++

Section filtering is suitably supported, whereby it may be decided whichsections to place in the user's circular buffer, for example when, dueto high rates, it is necessary to discard many sections. In somecircumstances it is desired that some section filters be enabled whenother filters have matched. This is described as an action on thematching filter. There are 32 filters, and any of them may haveactions—though there should never be more than 8 with actions associatedat any one time.

In the filtering software it must be checked whether a match is presentbetween 32 bits of data, a 32 bit mask which indicates which filters arecurrently enabled and a 32 bit mask indicating any filtering to beapplied. These could be checked using a simple 32 pass loop, to checkeach bit position one-by-one. However, due to time constraints it wouldbe greatly preferably to avoid this. Therefore, in the present systemthe following are stored:

-   -   1) a list of masks each with one bit set for each filter with        associated actions    -   2) a matching list containing 32 bit masks of those filters to        be enabled on a match    -   3) conglomerate masks indicating which filters have actions        associated with them.

The procedure then is to use the conglomerate masks to check if anyaction task needs to be done, if it does then the list is scanned ANDingthe entry from list 1. If a non zero result is achieved then thecorresponding entry from list 2 is ORed in to the mask of which filtersare currently enabled.

When a user wishes to send out packets on the (“alternate”) outputstream a mechanism is needed that, within the software driver on theuser hardware can control the insertion of the packets. In the presentsystem a circular list is used to address this problem. A circular listof “carousel” entries is provided. Each entry contains a packet and somecontrol information. The carousel management process cycles round thelist transmitting those entries that are set to be transmitted. An entrymay be in one of several states, disabled, one_shot_inject (signifyingthat it is to be disabled after transmission), repeated_inject_as_is(indicating that it should be repeatedly injected as-is),repeated_inject_with_cc_fixup (indicating that it should be repeatedlyinjected with that packed being adjusted to correct continuity counts).Interval controls are provided to allow the retransmission rate etc. tobe specified.

This approach allows several potential problems that could confront theuser to be addressed. In a real transport stream it is normal forsection information to be transmitted every ½ second or so. Using thecarousel as described above removes the overhead for this from the userand allows the driver to manage stream integrity.

In the system of FIG. 5 the decoder is configured so that the errorchecking of section data is transparent to user code. The process forachieving this is illustrated in FIG. 6.

FIG. 6 illustrates a region of memory in the main memory 15. One part 30of the memory stores received section data. Another part 31 of thememory stores pointers QW and R which point to a memory addresses inpart 30. Memory in the processing unit 16 stores another pointer W whichalso points to a memory address in part 30. For illustration the currentaddresses indicated by R, QW and W are shown at 32, 33 and 34respectively in FIG. 6. Pointer R represents a read pointer. Pointer QWrepresents a quantised write pointer. Pointer W represents a writepointer. The contents of the memory 31, representing pointers 32 and 33,are available to user code. The pointer W is preferably not directlyavailable to user code. The extent of part 30 of the memory is known tothe processor 16 and to the user code, and part 30 of the memory isconsidered to wrap around from upper boundary 35 to lower boundary 36.

The operation of the decoder for decoding section data and making itavailable to user code will now be described.

In the user code pointer R is interpreted as a read pointer, indicatingthe next address in the memory 15 from which the user code is to readand process the section data. As section data is read by the user codethe user code updates the pointer R accordingly. The pointer QW isinterpreted by the user code as a limit pointer beyond which the pointerR may not pass. If the pointer R meets the pointer QW then the user codemust consider that no unread section data is currently available.

In the processor 16, initially pointers W and QW are set to the firstaddress in buffer 30 of memory 15. Incoming section data is extractedfrom received packets. Each incoming part of section data is stored atthe write pointer. Then the write pointer is incremented by the lengthof that part so that it is points to a location immediately after thelast written part. This process continues as section data is normallyreceived, until check digit information for a received complete section(stored between the QW and W pointers) is received. At that stage a CRCfor the received data—which could be calculated at that time or couldmore preferably be built up as each incoming section is received—ischecked, for example, by comparison with a received CRC or apredetermined value such as zero. If the CRC for the received data iscorrects match then pointer QW is set to the value of pointer W and theprocess continues; this adjustment of the pointer QW makes the newlychecked section data available to the user code. If the CRCs do notmatch then the value of pointer W is set to the value of pointer QW;this means that the possible erroneous data is not made available to theuser code, and will be overwritten by subsequently received sectiondata.

The ongoing CRC testing may be performed by loading a value of −1 into amemory before reception of a section begins, combining that value witheach received byte of the section in turn including one or more CRCbytes of the section, and comparing the resulting value with zero. Ifthe resulting value is zero then the section may be deemed to have beencorrectly received, and otherwise incorrectly received.

During reception of section data two other errors in addition to the“CRC fail” error are acted upon by the processor 16. Each packetcontaining section data has a serial number. If a section is detected ashaving been received out of order then a “CC (continuity count) fail”error is indicated and the value of pointer W is set to the value ofpointer QW. If (following a wrap-around of pointer W) the pointer Wmeets pointer R then the buffer 30 is interpreted as having overflowed.To avoid correctly received but unread data (located after the pointerR) being overwritten the value of pointer W is set to the value ofpointer QW.

Thus, on completion of any group of received sections the pointer QW isset to the position of pointer W, and on detection of any error thepointer W is set to the position of pointer QW.

In the system of FIG. 6 the interface available to the user code isdesigned so that the user code has no access to the pointer W. The usercode is unaware of the position of pointer W. The user code can,however, safely read data up to pointer QW. Therefore the error checkingof section data that is performed by the processor 16 is transparent tothe user code.

One buffer as shown in FIG. 6 with respective associated pointers W, QWand R may be maintained for each PID from which section data is to bereceived. When the PID is selected by the user code for reception theuser code allocates in memory 15 the buffer indicated in FIG. 6 at 30and 31 and informs the processor 16 of the address and length of thebuffer. When the user shuts down a channel the processor 16 flushes thebuffer for that channel and sets the associated QW pointers to the valueof the associated W pointer.

The applicant draws attention to the fact that the present invention mayinclude any feature or combination of features disclosed herein eitherimplicitly or explicitly or any generalisation thereof, withoutlimitation to the scope of any of the present claims. In view of theforegoing description it will be evident to a person skilled in the artthat various modifications may be made within the scope of theinvention.

1. Data reception apparatus for receiving and processing a data streamincluding a stream of data units, the data reception apparatuscomprising: a buffer, a data reception controller for receiving dataunits from the data stream, storing received data units in the buffer,and if the amount of data from the data stream that is stored in thebuffer exceeds a predetermined amount, generating a buffer loadinterrupt for the data stream; and a processor responsive to the bufferload interrupt to: a) disable handling of further buffer load interruptsfor the data stream; and b) repeatedly activate a routine to process asingle data unit from the data stream that is stored in the buffer untilall the data units in the buffer have been processed and then reset thebuffer load interrupt.
 2. Data reception apparatus as claimed in claim1, wherein the processor is arranged to activate the said routine inresponse to a semaphore indicating that data in the buffer is to beprocessed.
 3. Data reception apparatus as claimed in claim 2, whereinthe routine is arranged to deactivate the semaphore.
 4. Data receptionapparatus as claimed in claim 2 or 3, wherein the routine is arranged tocall a subroutine to determine whether all the data units in the bufferhave been processed operable by the processor and if all the data unitsin the buffer have been processed to reset the buffer load interrupt andotherwise to activate the semaphore.
 5. Data reception apparatus asclaimed in claim 4, wherein the said subroutine is arranged to reset thebuffer if all the data units in the buffer have been processed.
 6. Datareception apparatus as claimed in any preceding claim, wherein the datareception apparatus is provided on a single integrated circuit.
 7. Datareception apparatus as claimed in any preceding claim, wherein the datastream is formed of packets and the data units are comprised within thepackets.
 8. Data reception apparatus as claimed in claim 7, wherein thedata stream is in accordance with the ITU-T H.222 standard or aderivative thereof. 9-10. (canceled).
 11. A method for receiving andprocessing a data stream including a stream of data units, the methodcomprising: receiving data units from the data stream; storing receiveddata units in a buffer, and if the amount of data from the data streamthat is stored in the buffer exceeds a predetermined amount, generatinga buffer load interrupt for the data stream; and performing processingby means of a processor responsive to the buffer load interrupt to: a)disable handling of further buffer load interrupts for the data stream;and b) repeatedly activate a routine to process a single data unit fromthe data stream that is stored in the buffer until all the data units inthe buffer have been processed and then reset the buffer load interrupt.12-13. (canceled)
 14. A data handling system, comprising: a transportcontrol processing device that assigns different portions of a receiveddata stream to different ones of a plurality of slots, sets an interruptassociated with a slot when a portion of the received data stream hasbeen assigned to that slot, and handles each interrupt by: disablingfurther interrupts on a slot where an interrupt is already set; andexecuting an input process for that slot which loops to continue tohandle data in the portion of the received data stream which is assignedto that slot until all data present in that slot is read and then resetthe interrupt for that slot.
 15. The data handling system of claim 14wherein at least one of the plurality of slots is a buffer memory thatstores the assigned portion of the received data stream and includes aread pointer, the executing of the input process by the transportcontrol processing device looping to read a data unit of the assignedportion stored in the buffer memory at a location identified by the readpointer, updating the read pointer and repeating until all data presentin that slot is read.
 16. The data handling system of claim 15 whereinthe buffer memory is a circular buffer.
 17. The data handling system ofclaim 15 wherein the transport control processing device signals a dataread semaphore when the data unit is ready to be read from the buffermemory, the executing of the input process by the transport controlprocessing device checking the data read semaphore before reading thedata unit of the assigned portion stored in the buffer memory at thelocation identified by the read pointer.
 18. The data handling system ofclaim 14, the executing of the input process by the transport controlprocessing device further re-enabling further interrupts for that slot.20. The data handling system of claim 14, the executing of the inputprocess by the transport control processing device looping to read adata unit of the assigned portion present in that slot and repeatinguntil all data present in that slot is read.
 21. The data handlingsystem of claim 20 wherein the transport control processing devicesignals a data read semaphore when the data unit is ready to be readfrom that slot, the executing of the input process by the transportcontrol processing device checking the data read semaphore beforereading the data unit of the assigned portion from that slot.
 22. A datahandling method, comprising: assigning different portions of a receiveddata stream to different ones of a plurality of slots setting aninterrupt associated with a slot when a portion of the received datastream has been assigned to that slot; and handling each interrupt by:disabling further interrupts on a slot where an interrupt is alreadyset; and executing an input process for that slot by: looping tocontinue to handle data in the portion of the received data stream whichis assigned to that slot until all data present in that slot is read;and then reset the interrupt for that slot.
 23. The data handling methodof claim 22 wherein assigning includes storing the assigned portion ofthe received data stream in a buffer memory which includes a readpointer, and wherein looping comprises: reading a data unit of theassigned portion from a location in the buffer memory identified by theread pointer; and updating the read pointer.
 24. The data handlingmethod of claim 23 wherein the buffer memory is a circular buffer. 25.The data handling method of claim 23 further comprising: signaling adata read semaphore when the data unit is ready to be read from thebuffer memory, and wherein looping comprises checking the data readsemaphore before reading the data unit of the assigned portion stored inthe buffer memory at the location identified by the read pointer. 26.The data handling method of claim 22, wherein executing furthercomprises re-enabling further interrupts for that slot.
 27. The datahandling system of claim 22, wherein looping comprises: looping to reada data unit of the assigned portion present in that slot; and repeatinguntil all data present in that slot is read.
 28. The data handlingmethod of claim 27 further comprising signaling the data read semaphorewhen the data unit is ready to be read from that slot, and whereinexecuting comprises checking the data read semaphore before reading thedata unit of the assigned portion from that slot.